In existing Service-Oriented Architecture (SOA) systems, a Service Provider provides a service, and a Service Consumer invokes the service. In the applications of Service-Oriented Architecture, a Service Consumer is not generally a final user, such as one of the consumers of a bank, but might be the developer who develops service-invoking programs, or the service-invoking program itself (e.g., service-invoking client program). The above fact is well known to a person of skill in the art. The Service consumer needs two types of information: service address, i.e. endpoint; and service interface information, which is normally described in Web Service Description Language (WSDL), wherein the service interface information is like a contract agreed to between the Service Provider and the Service Consumer. The service interface information specifies the information that a service provider asks a service consumer to provide and the format of the information, and once the interface information is specified, it will not change frequently.
In order to invoke a service, a service consumer needs to generate messages of a certain format according to the WSDL, e.g. a Simple Object Access Protocol (SOAP) message, and then send the messages to a service realization endpoint of a service to invoke the service. Each service may contain multiple different service realization endpoints, e.g. each service realization endpoint may correspond to a different service quality.
In a simple architecture of SOA, it is only necessary to have a service provider and a service consumer. However, in a complex architecture of SOA, a module may be provided between a service provider and a service consumer, which is normally called “message mediation”. The message mediation is used for handling the routings of service request messages among multiple service providers (i.e. specifying by which service provider a request message of a service shall be handled and the service provided and to which service realization endpoint the request message is sent). The above message mediation also needs some extra information (i.e. property information) to finalize the routings of the messages.
The property information can be constants, or values through calculations on the service interface information. When a system architecture designer designs the whole system, he can make the routing policies according to his specific business requirements, and then, input items for the property information can be set according to these specific routing policies. Service consumers input the requested property information when requesting the services.
For example, FIG. 1 depicts a system 100 of prior art for invoking services, which shows a general architecture for the application of a Service-Oriented Architecture.
The system 100 in FIG. 1 comprises a message mediation 120 and a service 110. The service 110 contains multiple service realization endpoints (e.g., service realization endpoint A, B, C etc.). The service can be a Web Service.
The message mediation 120 includes a semantic mediation engine 121 and a service metadata repository 122. The policies and the service realization endpoints (e.g. A, B, C etc.) are stored in the service metadata repository 122.
As shown in FIG. 1, the service consumer (not shown) will send a SOAP requesting message which contains the property information to the semantic mediation engine 121 in the message mediation 120. Wherein, the property information can, for example, be responding time, credit value etc.
The semantic mediation engine 121 will retrieve the service metadata repository 122 based on the property information in the header of the SOAP requesting message, in order to retrieve a proper service realization endpoint according to corresponding policies, and then dynamically route the requesting message to the proper service realization endpoint 110-A, 110-B or 110-C (here 110-A in FIG. 1) based on the retrieved endpoint, thereby finalizing a service invoking procedure.
In existing Web service SOA systems, a method for passing messages based on text (actually based on Extensible Markup Language—XML) is provided. For instance, Simple Object Access Protocol (SOAP) is a standard method for invoking Web services. The format of a SOAP message is defined in the specification of SOAP, wherein, a SOAP message includes a SOAP envelop, a SOAP message header and a SOAP message body. SOAP messages are based on XML.
The SOAP message header can provide information regarding the message itself, e.g. the property information used for routing described above. The SOAP message body is used for providing information for the application, i.e. the service interface information. The mediation engine normally adopts the property information in the message header to make routing decisions, since this can reduce the time for the analysis for the SOAP message body. The following is an example of a SOAP message.
<?xml version=“1.0”?><SOAP-ENV:Envelopexmlns:SOAP-ENV=“http://schemas.xmlsoap.org/soap/envelope/” > < SOAP-ENV:Header>   <t1:score xmlns:t1=“http://www.ibm.com/abc”>120   </t1:score>  </ SOAP-ENV:Header>  <SOAP-ENV:Body>    <m:getListOfModels xmlns:m=“urn:MobilePhoneservice” >    </m:getListOfModels>  </SOAP-ENV:Body></SOAP-ENV:Envelope>
When a client sends a SOAP message to a server, the SOAP message can be transmitted with HTTP protocol. This is called a binding of SOAP and HTTP. In order to send a SOAP/HTTP request, it is necessary to provide a SOAPAction field in the HTTP header. The SOAPAction specifies the destination of the SOAP request. The following is an example of a message for the binding of SOAP and HTTP protocol.
POST /Vendors HTTP/1.1Host: www.mobilephoneservice.comContent-Type:“text/xml”;Charset=“utf-8”Content-Length: nnnnSOAPACtion:“www.mobilephoneservice.com/Vendors/MobilePhoneservice#getListOfModels”<?xml version=“1.0”?><SOAP-ENV:Envelopexmlns:SOAP-ENV=“http://schemas.xmlsoap.org/soap/envelope/” > < SOAP-ENV:Header>  <t1:score xmlns:t1=“http://www.ibm.com/abc”>120  </t1:score> </ SOAP-ENV:Header> <SOAP-ENV:Body>   <m:getListOfModels xmlns:m=“urn:MobilePhoneservice” >   </m:getListOfModels> </SOAP-ENV:Body></SOAP-ENV:Envelope>
It is apparent that SOAP messages are based on XML, wherein, the process to produce a SOAP message is to make up a XML file, while the destination address of the SOAP message is provide in the HTTP header.
In the developing process of a client program which invokes Web services, the construction of a SOAP message (XML file) is rather burdensome. Luckily, there exist many mature applications, which can produce client code for invoking corresponding Web services according to Web Service Description Language (WSDL). For instance, WSDL2Java application can produce Java code according to WSDL, wherein a client program developer can set the parameters of invoking services through manipulating Java objects, and the SOAP messages based on XML will be automatically generated, facilitating the development of client developers to a great degree. Meanwhile, the Java code of a Web service client also provides the function of setting the transmitting destination address of the SOAP message, i.e. an Application Program Interface (API) is provided for setting the destination address in the HTTP header.
In existing systems, after the SOAP message has been generated, there exist two ways to insert property information into the header of a SOAP message. One way is to develop a Web service handling program, in which, the XML file is manipulated through an API in order to insert necessary property information into the header of the SOAP message. The other way is to add explicit SOAP message header definition by manually modifying WSDL, so as to generate a new client Java code by the modified WSDL. Because the client Java code includes APIs designed to manipulate the header of the SOAP message, it is possible to set the value of the header of the SOAP message by a manner of manipulating Java objects. Both of the ways will introduce extra work into the development of the client program. Moreover, manual operations by developers will lead to a higher percent of errors.